FCS_COP.1/DataEncryption Cryptographic Operation (AES Data Encryption/Decryption)

There is no change to the Evaluation Activities specified for this SFR in the NDcPP Supporting Document. The PP-Module modifies this SFR to require the ST author to make certain selections, but these selections are all part of the original definition of the SFR so no new behavior is defined by the PP-Module.

FCS_IPSEC_EXT.1 IPsec Protocol

In addition to the Evaluation Activities specified for this SFR in the NDcPP Supporting Document the following activities apply: All existing activities regarding "Pre-shared keys" apply to all selections including pre-shared keys. If any selection with "Pre-shared keys" is included, the evaluator shall check to ensure that the TSS describes how the selection works in conjunction with the authentication of IPsec connections.
If any selection with “Pre-shared Keys” is selected, the evaluator shall check that the operational guidance describes any configuration necessary to enable any selected authentication mechanisms.
There are no additional testing activities.

FIA_X509_EXT.1/Rev X.509 Certificate Validation

There is no change to the Evaluation Activities specified for this SFR in the NDcPP Supporting Document. The PP-Module modifies this SFR to make it mandatory because of the TOE’s required support for IPsec.

FIA_X509_EXT.2 X.509 Certificate Authentication

There is no change to the Evaluation Activities specified for this SFR in the NDcPP Supporting Document. The PP-Module modifies this SFR to support its use for IPsec at a minimum. The evaluator shall ensure that all evaluation of this SFR is performed against its use in IPsec communications as well as any other supported usage.

FIA_X509_EXT.3 X.509 Certificate Requests

There is no change to the Evaluation Activities specified for this SFR in the NDcPP Supporting Document. The PP-Module modifies this SFR to make it mandatory because of the TOE’s required support for IPsec.

FMT_MTD.1/CryptoKeys Management of TSF Data

There is no change to the Evaluation Activities specified for this SFR in the NDcPP Supporting Document. The PP-Module modifies this SFR to make it mandatory because of the TOE’s required support for IPsec.

FPT_TST_EXT.1 TSF Testing

There is no change to the Evaluation Activities specified for this SFR in the NDcPP Supporting Document. The PP-Module requires a particular self-test to be performed, but this self-test is still evaluated using the same methods specified in the Supporting Document.

FPT_TUD_EXT.1 Trusted Update

There is no change to the Evaluation Activities specified for this SFR in the NDcPP Supporting Document. The PP-Module modifies this SFR to mandate that a particular selection be chosen, but this selection is part of the original definition of the SFR so no new behavior is defined by the PP-Module.

FAU_GEN.1/VPN Audit Data Generation (VPN Gateway)

The evaluator shall examine the TSS to verify that it describes the audit mechanisms that the TOE uses to generate audit records for VPN gateway behavior. If any audit mechanisms the TSF uses for this are not used to generate audit records for events defined by FAU_GEN.1 in the Base-PP, the evaluator shall ensure that any VPN gateway-specific audit mechanisms also meet the relevant functional claims from the Base-PP.
For example, FAU_STG_EXT.1 requires all audit records to be transmitted to the OE over a trusted channel. This includes the audit records that are required by FAU_GEN.1/VPN. Therefore, if the TOE has an audit mechanism that is only used for VPN gateway functionality, the evaluator shall ensure that the VPN gateway related audit records meet this requirement, even if the mechanism used to generate these audit records does not apply to any of the auditable events defined in the Base-PP.
The evaluator shall examine the operational guidance to verify that it identifies all security-relevant auditable events claimed in the ST and includes sample records of each event type. If the TOE uses multiple audit mechanisms to generate different sets of records, the evaluator shall verify that the operational guidance identifies the audit records that are associated with each of the mechanisms such that the source of each audit record type is clear.
The evaluator shall test the audit functionality by performing actions that trigger each of the claimed audit events and verifying that the audit records are accurate and that their format is consistent with what is specified in the operational guidance. The evaluator may generate these audit events as a consequence of performing other tests that would cause these events to be generated.

FCS_CKM.1/IKE Cryptographic Key Generation (for IKE Peer Authentication)

The evaluator shall check to ensure that the TSS describes how the key-pairs are generated. In order to show that the TSF implementation complies with FIPS PUB 186-4, the evaluator shall ensure that the TSS contains the following information:

• The TSS shall list all sections of Appendix B to which the TOE complies
• For each applicable section listed in the TSS, for all statements that are not "shall" (that is, "shall not," "should," and "should not"), if the TOE implements such options it shall be described in the TSS. If the included functionality is indicated as "shall not" or "should not" in the standard, the TSS shall provide a rationale for why this will not adversely affect the security policy implemented by the TOE
• For each applicable section of Appendix B, any omission of functionality related to "shall" or “should” statements shall be described

Any TOE-specific extensions, processing that is not included in the Appendices, or alternative implementations allowed by the Appendices that may impact the security requirements the TOE is to enforce shall be described.
The evaluator shall check that the operational guidance describes how the key generation functionality is invoked, and describes the inputs and outputs associated with the process for each signature scheme supported. The evaluator shall also check that guidance is provided regarding the format and location of the output of the key generation process.
For FFC Schemes using “safe-prime” groups:
Testing for FFC Schemes using safe-prime groups is done as part of testing in FCS_CKM.2.
For all other selections:
The evaluator shall perform the corresponding tests for FCS_CKM.1 specified in the NDcPP SD, based on the selections chosen for this SFR. If IKE key generation is implemented by a different algorithm than the NDcPP key generation function, the evaluator shall ensure this testing is performed using the correct implementation.

FMT_SMF.1/VPN Specification of Management Functions

The evaluator shall examine the TSS to confirm that all management functions specified in FMT_SMF.1/VPN are provided by the TOE. As with FMT_SMF.1 in the Base-PP, the evaluator shall ensure that the TSS identifies what logical interfaces are used to perform these functions and that this includes a description of the local administrative interface.
The evaluator shall examine the operational guidance to confirm that all management functions specified in FMT_SMF.1/VPN are provided by the TOE. As with FMT_SMF.1 in the Base-PP, the evaluator shall ensure that the operational guidance identifies what logical interfaces are used to perform these functions and that this includes a description of the local administrative interface.
The evaluator tests management functions as part of performing other test EAs. No separate testing for FMT_SMF.1/VPN is required unless one of the management functions in FMT_SMF.1.1/VPN has not already been exercised under any other SFR.

FPF_RUL_EXT.1 Packet Filtering Rules

The evaluator shall verify that the TSS provide a description of the TOE’s initialization and startup process, which clearly indicates where processing of network packets begins to take place, and provides a discussion that supports the assertion that packets cannot flow during this process.
The evaluator shall verify that the TSS also includes a narrative that identifies the components (e.g., active entity such as a process or task) involved in processing the network packets and describes the safeguards that would prevent packets flowing through the TOE without applying the ruleset in the event of a component failure. This could include the failure of a component, such as a process being terminated, or a failure within a component, such as memory buffers full and cannot process packets.

The operational guidance associated with this requirement is assessed in the subsequent test EAs.

The evaluator shall perform the following tests:

• Test 1: The evaluator shall attempt to get network traffic to flow through the TOE while the TOE is being initialized. A steady flow of network packets that would otherwise be denied by the ruleset should be sourced and directed to a host. The evaluator shall use a packet sniffer to verify none of the generated network traffic is permitted through the TOE during initialization.
• Test 2: The evaluator shall attempt to get network traffic to flow through the TOE while the TOE is being initialized. A steady flow of network packets that would be permitted by the ruleset should be sourced and directed to a host. The evaluator shall use a packet sniffer to verify none of the generated network traffic is permitted through the TOE during initialization and is only permitted once initialization is complete.

Note: The remaining testing associated with application of the ruleset is addressed in the subsequent test EAs.

There are no EAs specified for this element. Definition of packet filtering policy, association of operations with packet filtering rules, and association of these rules to network interfaces is described collectively under FPF_RUL_EXT.1.4. There are no EAs specified for this element. Definition of packet filtering policy, association of operations with packet filtering rules, and association of these rules to network interfaces is described collectively under FPF_RUL_EXT.1.4. The evaluator shall verify that the TSS describes a packet filtering policy that can use the following fields for each identified protocol, and that the RFCs identified for each protocol are supported:

• IPv4 (RFC 791)
• source address
• destination address
• protocol
• IPv6 (RFC 2460)
• source address
• destination address
• next header (protocol)
• TCP (RFC 793)
• source port
• destination port
• UDP (RFC 768)
• source port
• destination port

The evaluator shall verify that the TSS describes how conformance with the identified RFCs has been determined by the TOE developer (e.g., third party interoperability testing, protocol compliance testing).
The evaluator shall verify that each rule can identify the following actions: permit, discard, and log.
The evaluator shall verify that the TSS identifies all interface types subject to the packet filtering policy and explains how rules are associated with distinct network interfaces. Where interfaces can be grouped into a common interface type (e.g., where the same internal logical path is used, perhaps where a common device driver is used), they can be treated collectively as a distinct network interface.

The evaluator shall verify that the operational guidance identifies the following protocols as being supported and the following attributes as being configurable within packet filtering rules for the associated protocols:

• IPv4 (RFC 791)
• destination address
• protocol
• IPv6 (RFC 2460)
• source address
• destination address
• next header (protocol)
• TCP (RFC 793)
• source port
• destination port
• UDP (RFC 768)
• source port
• destination port

The evaluator shall verify that the operational guidance indicates that each rule can identify the following actions: permit, discard, and log.
The evaluator shall verify that the operational guidance explains how rules are associated with distinct network interfaces.
The guidance may describe the other protocols contained within the ST (e.g., IPsec, IKE, potentially HTTPS, SSH, and TLS) that are processed by the TOE. The evaluator shall ensure that it is made clear what protocols were not considered as part of the TOE evaluation.

The evaluator shall perform the following tests:

• Test 1: The evaluator shall use the instructions in the operational guidance to test that packet filter rules can be created that permit, discard, and log packets for each of the following attributes:
  • IPv4
  • Destination Address
  • Protocol
  • IPv6
  • Source address
  • Destination Address
  • Next Header (Protocol)
  • TCP
  • Source Port
  • Destination Port
  • UDP
  • Source Port
  • Destination Port
• Test 2: The evaluator shall repeat Test 1 above for each distinct network interface type supported by the TOE to ensure that packet filtering rules can be defined for all supported types.

Note that these test activities should be performed in conjunction with those of FPF_RUL_EXT.1.6 where the effectiveness of the rules is tested; here the evaluator is just ensuring the guidance is sufficient and the TOE supports the administrator creating a ruleset based on the above attributes. The test activities for FPF_RUL_EXT.1.6 define the combinations of protocols and attributes required to be tested. If those combinations are configured manually, that will fulfill the objective of these test activities, but if those combinations are configured otherwise (e.g., using automation), these test activities may be necessary in order to ensure the guidance is correct and the full range of configurations can be achieved by a TOE administrator.

The evaluator shall verify that the TSS describes the algorithm applied to incoming packets, including the processing of default rules, determination of whether a packet is part of an established session, and application of administrator defined and ordered ruleset.

The evaluator shall verify that the operational guidance describes how the order of packet filtering rules is determined and provides the necessary instructions so that an administrator can configure the order of rule processing.

The evaluator shall perform the following tests:

• Test 1: The evaluator shall devise two equal packet filtering rules with alternate operations – permit and discard. The rules should then be deployed in two distinct orders and in each case the evaluator shall ensure that the first rule is enforced in both cases by generating applicable packets and using packet capture and logs for confirmation.
• Test 2: The evaluator shall repeat the procedure above, except that the two rules should be devised where one is a subset of the other (e.g. a specific address vs. a network segment). Again, the evaluator should test both orders to ensure that the first is enforced regardless of the specificity of the rule.

The evaluator shall verify that the TSS describes the process for applying packet filtering rules and also that the behavior (either by default, or as configured by the administrator) is to discard packets when there is no rule match. The evaluator shall verify the TSS describes when the IPv4 and IPv6 protocols supported by the TOE differ from the full list provided in the RFC Values for IPv4 and IPv6 table.

The evaluator shall verify that the operational guidance describes the behavior if no rules or special conditions apply to the network traffic. If the behavior is configurable, the evaluator shall verify that the operational guidance provides the appropriate instructions to configure the behavior to discard packets with no matching rules. The evaluator shall verify that the operational guidance describes the range of IPv4 and IPv6 protocols supported by the TOE.

The evaluator shall perform the following tests:

• Test 1: The evaluator shall configure the TOE to permit and log each supported IPv4 Transport Layer Protocol (see RFC Values for IPv4 and IPv6 table for full possible list) in conjunction with a specific source address and specific destination address, specific source address and wildcard destination address, wildcard source address and specific destination address, and wildcard source address and wildcard destination address. The evaluator shall generate packets matching each supported IPv4 Transport Layer Protocol and within the configured source and destination addresses in order to ensure that the supported protocols are permitted (i.e., by capturing the packets after passing through the TOE) and logged. Any protocols not supported by the TOE must be denied.
• Test 2: The evaluator shall configure the TOE to permit all traffic except to discard and log each supported IPv4 Transport Layer Protocol (see RFC Values for IPv4 and IPv6 table for full possible list) in conjunction with a specific source address and specific destination address, specific source address and wildcard destination address, wildcard source address and specific destination address, and wildcard source address and wildcard destination address. The evaluator shall generate packets matching each defined IPv4 Transport Layer Protocol and within the configured source and destination addresses in order to ensure that the supported protocols are denied (i.e., by capturing no applicable packets passing through the TOE) and logged. Any protocols not supported by the TOE must also be denied but are not required to be logged.
• Test 3: The evaluator shall configure the TOE to permit and log each supported IPv4 Transport Layer Protocol (see RFC Values for IPv4 and IPv6 table for full possible list) in conjunction with a specific source address and specific destination address, specific source address and wildcard destination address, wildcard source address and specific destination address, and wildcard source address and wildcard destination address. Additionally, the evaluator shall configure the TOE to discard and log each supported IPv4 Transport Layer Protocol (see RFC Values for IPv4 and IPv6 table for full possible list) in conjunction with different (than those permitted above) combinations of a specific source address and specific destination address, specific source address and wildcard destination address, wildcard source address and specific destination address, and wildcard source address and wildcard destination address. The evaluator shall generate packets matching each supported IPv4 Transport Layer Protocol and outside the scope of all source and destination addresses configured above in order to ensure that the supported protocols are denied (i.e., by capturing no applicable packets passing through the TOE) and logged. Any protocols not supported by the TOE must be denied.
• Test 4: The evaluator shall configure the TOE to permit and log each supported IPv6 Transport Layer Protocol (see RFC Values for IPv4 and IPv6 table for full possible list) in conjunction with a specific source address and specific destination address, specific source address and wildcard destination address, wildcard source address and specific destination address, and wildcard source address and wildcard destination address. The evaluator shall generate packets matching each defined IPv6 Transport Layer Protocol and within the configured source and destination addresses in order to ensure that the supported protocols are permitted (i.e., by capturing the packets after passing through the TOE) and logged. Any protocols not supported by the TOE must be denied.
• Test 5: The evaluator shall configure the TOE to permit all traffic except to discard and log each supported IPv6 Transport Layer Protocol (see RFC Values for IPv4 and IPv6 table for full possible list) in conjunction with a specific source address and specific destination address, specific source address and wildcard destination address, wildcard source address and specific destination address, and wildcard source address and wildcard destination address. The evaluator shall generate packets matching each defined IPv6 Transport Layer Protocol and within the configured source and destination addresses in order to ensure that the supported protocols are denied (i.e., by capturing no applicable packets passing through the TOE) and logged. Any protocols not supported by the TOE must also be denied but are not required to be logged.
• Test 6: The evaluator shall configure the TOE to permit and log each supported IPv6 Transport Layer Protocol (see RFC Values for IPv4 and IPv6 table for full possible list) in conjunction with a specific source address and specific destination address, specific source address and wildcard destination address, wildcard source address and specific destination address, and wildcard source address and wildcard destination address. Additionally, the evaluator shall configure the TOE to discard and log each supported IPv6 Transport Layer Protocol (see RFC Values for IPv4 and IPv6 table for full possible list) in conjunction with different (than those permitted above) combinations of a specific source address and specific destination address, specific source address and wildcard destination address, wildcard source address and specific destination address, and wildcard source address and wildcard destination address. The evaluator shall generate packets matching each defined IPv6 Transport Layer Protocol and outside the scope of all source and destination addresses configured above in order to ensure that the supported protocols are dropped (i.e., by capturing no applicable packets passing through the TOE) and logged. Any protocols not supported by the TOE must be denied.
• Test 7: The evaluator shall configure the TOE to permit and log protocol 6 (TCP) using a selected source port, a selected destination port, and a selected source and destination port combination. The evaluator shall generate packets matching the configured source and destination TCP ports in order to ensure that they are permitted (i.e., by capturing the packets after passing through the TOE) and logged.
• Test 8: The evaluator shall configure the TOE to discard and log protocol 6 (TCP) using a selected source port, a selected destination port, and a selected source and destination port combination. The evaluator shall generate packets matching the configured source and destination TCP ports in order to ensure that they are denied (i.e., by capturing no applicable packets passing through the TOE) and logged.
• Test 9: The evaluator shall configure the TOE to permit and log protocol 17 (UDP) using a selected source port, a selected destination port, and a selected source and destination port combination. The evaluator shall generate packets matching the configured source and destination UDP ports in order to ensure that they are permitted (i.e., by capturing the packets after passing through the TOE) and logged. Here the evaluator ensures that the UDP port 500 (IKE) is included in the set of tests.
• Test 10: The evaluator shall configure the TOE to discard and log protocol 17 (UDP) using a selected source port, a selected destination port, and a selected source and destination port combination. The evaluator shall generate packets matching the configured source and destination UDP ports in order to ensure that they are denied (i.e., by capturing no applicable packets passing through the TOE) and logged. Again, the evaluator ensures that UDP port 500 is included in the set of tests.

The following table identifies the RFC defined values for the protocol fields for IPv4 and IPv6 to be used in configuring and otherwise testing packet filtering rule definition and enforcement:

Protocol	Defined Attributes
IPv4	Transport Layer Protocol 1 - Internet Control Message Transport Layer Protocol 2 - Internet Group Management Transport Layer Protocol 3 - Gateway-to-Gateway Transport Layer Protocol 4 - IP in IP (encapsulation) Transport Layer Protocol 5 - Stream Transport Layer Protocol 6 - Transmission Control Transport Layer Protocol 7 - UCL Transport Layer Protocol 8 - Exterior Gateway Protocol Transport Layer Protocol 9 - Any private interior gateway Transport Layer Protocol 10 - BBN RCC Monitoring Transport Layer Protocol 11 - Network Voice Protocol Transport Layer Protocol 12 - PUP Transport Layer Protocol 13 - ARGUS Transport Layer Protocol 14 - EMCON Transport Layer Protocol 15 - Cross Net Debugger Transport Layer Protocol 16 - Chaos Transport Layer Protocol 17 - User Datagram Transport Layer Protocol 18 - Multiplexing Transport Layer Protocol 19 - DCN Measurement Subsystems Transport Layer Protocol 20 - Host Monitoring Transport Layer Protocol 21 - Packet Radio Measurement Transport Layer Protocol 22 - XEROX NS IDP Transport Layer Protocol 23 - Trunk-1 Transport Layer Protocol 24 - Trunk-2 Transport Layer Protocol 25 - Leaf-1 Transport Layer Protocol 26 - Leaf-2 Transport Layer Protocol 27 - Reliable Data Protocol Transport Layer Protocol 28 - Internet Reliable Transaction Transport Layer Protocol 29 - ISO Transport Protocol Class 4 Transport Layer Protocol 30 - Bulk Data Transfer Protocol Transport Layer Protocol 31 - MFE Network Services Protocol Transport Layer Protocol 32 - MERIT Internodal Protocol Transport Layer Protocol 33 - Sequential Exchange Protocol Transport Layer Protocol 34 - Third Party Connect Protocol Transport Layer Protocol 35 - Inter-Domain Policy Routing Protocol Transport Layer Protocol 36 - XTP Transport Layer Protocol 37 - Datagram Delivery Protocol Transport Layer Protocol 38 - IDPR Control Message Transport Protocol Transport Layer Protocol 39 - TP++ Transport Protocol Transport Layer Protocol 40 - IL Transport Protocol Transport Layer Protocol 41 - Simple Internet Protocol Transport Layer Protocol 42 - Source Demand Routing Protocol Transport Layer Protocol 43 - SIP Source Route Transport Layer Protocol 44 - SIP Fragment Transport Layer Protocol 45 - Inter-Domain Routing Protocol Transport Layer Protocol 46 - Reservation Protocol Transport Layer Protocol 47 - General Routing Encapsulation Transport Layer Protocol 48 - Mobile Host Routing Protocol Transport Layer Protocol 49 - BNA Transport Layer Protocol 50 - SIPP Encap Security Payload Transport Layer Protocol 51 - SIPP Authentication Header Transport Layer Protocol 52 - Integrated Net Layer Security TUBA Transport Layer Protocol 53 - IP with Encryption Transport Layer Protocol 54 - NBMA Next Hop Resolution Protocol Transport Layer Protocol 61 - Any host internal protocol Transport Layer Protocol 62 - CFTP Transport Layer Protocol 63 - Any local network Transport Layer Protocol 64 - SATNET and Backroom EXPAK Transport Layer Protocol 65 - Kryptolan Transport Layer Protocol 66 - MIT Remote Virtual Disk Protocol Transport Layer Protocol 67 - Internet Pluribus Packet Core Transport Layer Protocol 68 - Any distributed file system Transport Layer Protocol 69 - SATNET Monitoring Transport Layer Protocol 70 - VISA Protocol Transport Layer Protocol 71 - Internet Packet Core Utility Transport Layer Protocol 72 - Computer Protocol Network Executive Transport Layer Protocol 73 - Computer Protocol Heart Beat Transport Layer Protocol 74 - Wang Span Network Transport Layer Protocol 75 - Packet Video Protocol Transport Layer Protocol 76 - Backroom SATNET Monitoring Transport Layer Protocol 77 - SUN ND PROTOCOL-Temporary Transport Layer Protocol 78 - WIDEBAND Monitoring Transport Layer Protocol 79 - WIDEBAND EXPAK Transport Layer Protocol 80 - ISO Internet Protocol Transport Layer Protocol 81 - VMTP Transport Layer Protocol 82 - SECURE-VMTP Transport Layer Protocol 83 - VINES Transport Layer Protocol 84 - TTP Transport Layer Protocol 85 - NSFNET-IGP Transport Layer Protocol 86 - Dissimilar Gateway Protocol Transport Layer Protocol 87 - TCF Transport Layer Protocol 88 - IGRP Transport Layer Protocol 89 - OSPFIGP Transport Layer Protocol 90 - Sprite RPC Protocol Transport Layer Protocol 91 - Locus Address Resolution Protocol Transport Layer Protocol 92 - Multicast Transport Protocol Transport Layer Protocol 93 - AX.25 Frames Transport Layer Protocol 94 - IP-within-IP Encapsulation Protocol Transport Layer Protocol 95 - Mobile Internetworking Control Protocol Transport Layer Protocol 96 - Semaphore Communications Security Protocol Transport Layer Protocol 97 - Ethernet-within-IP Encapsulation Transport Layer Protocol 98 - Encapsulation Header Transport Layer Protocol 99 - Any private encryption scheme Transport Layer Protocol 100 - GMTP
IPv6	Transport Layer Protocol 1 - Internet Control Message Transport Layer Protocol 2 - Internet Group Management Transport Layer Protocol 3 - Gateway-to-Gateway Transport Layer Protocol 4 - IPv4 encapsulation Transport Layer Protocol 5 - Stream Transport Layer Protocol 6 - Transmission Control Transport Layer Protocol 7 - CBT Transport Layer Protocol 8 - Exterior Gateway Protocol Transport Layer Protocol 9 - Any private interior gateway Transport Layer Protocol 10 - BBN RCC Monitoring Transport Layer Protocol 11 - Network Voice Protocol Transport Layer Protocol 12 - PUP Transport Layer Protocol 13 - ARGUS Transport Layer Protocol 14 - EMCON Transport Layer Protocol 15 - Cross Net Debugger Transport Layer Protocol 16 - Chaos Transport Layer Protocol 17 - User Datagram Transport Layer Protocol 18 - Multiplexing Transport Layer Protocol 19 - DCN Measurement Subsystems Transport Layer Protocol 20 - Host Monitoring Transport Layer Protocol 21 - Packet Radio Measurement Transport Layer Protocol 22 - XEROX NS IDP Transport Layer Protocol 23 - Trunk-1 Transport Layer Protocol 24 - Trunk-2 Transport Layer Protocol 25 - Leaf-1 Transport Layer Protocol 26 - Leaf-2 Transport Layer Protocol 27 - Reliable Data Protocol Transport Layer Protocol 28 - Internet Reliable Transaction Transport Layer Protocol 29 - Transport Protocol Class 4 Transport Layer Protocol 30 - Bulk Data Transfer Protocol Transport Layer Protocol 31 - MFE Network Services Protocol Transport Layer Protocol 32 - MERIT Internodal Protocol Transport Layer Protocol 33 - Datagram Congestion Control Protocol Transport Layer Protocol 34 - Third Party Connect Protocol Transport Layer Protocol 35 - Inter-Domain Policy Routing Protocol Transport Layer Protocol 36 - XTP Transport Layer Protocol 37 - Datagram Delivery Protocol Transport Layer Protocol 38 - IDPR Control Message Transport Protocol Transport Layer Protocol 39 - TP++ Transport Protocol Transport Layer Protocol 40 - IL Transport Protocol Transport Layer Protocol 41 - IPv6 encapsulation Transport Layer Protocol 42 - Source Demand Routing Protocol Transport Layer Protocol 43 - Intentionally blank Transport Layer Protocol 44 - Intentionally blank Transport Layer Protocol 45 - Inter-Domain Routing Protocol Transport Layer Protocol 46 - Reservation Protocol Transport Layer Protocol 47 - General Routing Encapsulation Transport Layer Protocol 48 - Dynamic Source Routing Protocol Transport Layer Protocol 49 - BNA Transport Layer Protocol 50 - Intentionally Blank Transport Layer Protocol 51 - Intentionally Blank Transport Layer Protocol 52 - Integrated Net Layer Security Transport Layer Protocol 53 - IP with Encryption Transport Layer Protocol 54 - NBMA Address Resolution Protocol Transport Layer Protocol 55 - Mobility Transport Layer Protocol 56 - Transport Layer Security Protocol using Kryptonet key management Transport Layer Protocol 57 - SKIP Transport Layer Protocol 58 - ICMP for IPv6 Transport Layer Protocol 59 - No Next Header for IPv6 Transport Layer Protocol 60 - Intentionally Blank Transport Layer Protocol 61 - Any host internal protocol Transport Layer Protocol 62 - CFTP Transport Layer Protocol 63 - Any local network Transport Layer Protocol 64 - SATNET and Backroom EXPAK Transport Layer Protocol 65 - Kryptolan Transport Layer Protocol 66 - MIT Remote Virtual Disk Protocol Transport Layer Protocol 67 - Internet Pluribus Packet Core Transport Layer Protocol 68 - Any distributed file system Transport Layer Protocol 69 - SATNET Monitoring Transport Layer Protocol 70 - VISA Protocol Transport Layer Protocol 71 - Internet Packet Core Utility Transport Layer Protocol 72 - Computer Protocol Network Executive Transport Layer Protocol 73 - Computer Protocol Heart Beat Transport Layer Protocol 74 - Wang Span Network Transport Layer Protocol 75 - Packet Video Protocol Transport Layer Protocol 76 - Backroom SATNET Monitoring Transport Layer Protocol 77 - SUN ND PROTOCOL-Temporary Transport Layer Protocol 78 - WIDEBAND Monitoring Transport Layer Protocol 79 - WIDEBAND EXPAK Transport Layer Protocol 80 - ISO Internet Protocol Transport Layer Protocol 81 - VMTP Transport Layer Protocol 82 - SECURE-VMTP Transport Layer Protocol 83 - VINES Transport Layer Protocol 84 - TTP Transport Layer Protocol 85 - Internet Protocol Traffic Manager Transport Layer Protocol 86 - NSFNET-IGP Transport Layer Protocol 87 - Dissimilar Gateway Protocol Transport Layer Protocol 88 - TCF Transport Layer Protocol 89 - EIGRP Transport Layer Protocol 90 - OSPFIGP Transport Layer Protocol 91 - Sprite RPC Protocol Transport Layer Protocol 92 - Locus Address Resolution Protocol Transport Layer Protocol 93 - Multicast Transport Protocol Transport Layer Protocol 94 - AX.25 Frames Transport Layer Protocol 95 - IP-within-IP Encapsulation Protocol Transport Layer Protocol 96 - Mobile Internetworking Control Pro. Transport Layer Protocol 97 - Semaphore Communications Sec. Pro. Transport Layer Protocol 98 - Ethernet-within-IP Encapsulation Transport Layer Protocol 99 - Encapsulation Header Transport Layer Protocol 100 - GMTP Transport Layer Protocol 101 - Ipsilon Flow Management Protocol Transport Layer Protocol 102 - PNNI over IP Transport Layer Protocol 103 - Protocol Independent Multicast Transport Layer Protocol 104 - ARIS Transport Layer Protocol 105 - SCPS Transport Layer Protocol Transport Layer Protocol 106 - QNX Transport Layer Protocol 107 - Active Networks Transport Layer Protocol 108 - Payload Compression Protocol Transport Layer Protocol 109 - Sitara Networks Protocol Transport Layer Protocol 110 - Compaq Peer Protocol Transport Layer Protocol 111 - IPX in IP Transport Layer Protocol 112 - Virtual Router Redundancy Protocol Transport Layer Protocol 113 - PGM Reliable Transport Protocol Transport Layer Protocol 114 - Any 0-hop protocol Transport Layer Protocol 115 - Layer Two Tunneling Protocol Transport Layer Protocol 116 - D-II Data Exchange (DDX) Transport Layer Protocol 117 - Interactive Agent Transfer Protocol Transport Layer Protocol 118 - Schedule Transfer Protocol Transport Layer Protocol 119 - SpectraLink Radio Protocol Transport Layer Protocol 120 - UTI Transport Layer Protocol 121 - Simple Message Protocol Transport Layer Protocol 122 - SM Transport Layer Protocol 123 - Performance Transparency Protocol Transport Layer Protocol 124 - ISIS over IPv4 Transport Layer Protocol 125 - FIRE Transport Layer Protocol 126 - Combat Radio Transport Protocol Transport Layer Protocol 127 - Combat Radio User Datagram Transport Layer Protocol 128 - SSCOPMCE Transport Layer Protocol 129 - IPLT Transport Layer Protocol 130 - Secure Packet Shield Transport Layer Protocol 131 - Private IP Encapsulation within IP Transport Layer Protocol 132 - Stream Control Transmission Protocol Transport Layer Protocol 133 - Fibre Channel Transport Layer Protocol 134 - RSVP-E2E-IGNORE Transport Layer Protocol 135 - Mobility Header Transport Layer Protocol 136 - UDPLite Transport Layer Protocol 137 - MPLS-in-IP Transport Layer Protocol 138 - MANET Protocols Transport Layer Protocol 139 - Host Identity Protocol Transport Layer Protocol 140 - Shim6 Protocol Transport Layer Protocol 141 - Wrapped Encapsulating Security Payload Transport Layer Protocol 142 - Robust Header Compression

: RFC Values for IPv4 and IPv6

FPT_FLS.1/SelfTest Failure with Preservation of Secure State (Self-Test Failures)

The evaluator shall ensure the TSS describes how the TOE ensures a shutdown upon a self-test failure, a failed integrity check of the TSF executable image, or a failed health test of the noise source. If there are instances when a shutdown does not occur, (e.g., a failure is deemed non- security relevant), the evaluator shall ensure that those cases are identified and a rationale is provided that supports the classification and justifies why the TOE’s ability to enforce its security policies is not affected in any such instance.
The evaluator shall verify that the operational guidance provides information on the self-test failures that can cause the TOE to shut down and how to diagnose the specific failure that has occurred, including possible remediation steps if available.
There are no test EAs for this component.

FPT_TST_EXT.3 Self-Test with Defined Methods

The evaluator shall verify that the TSS describes the method used to perform self-testing on the TSF executable code, and that this method is consistent with what is described in the SFR.
There are no guidance EAs for this component.
There are no test EAs for this component.

FTP_ITC.1/VPN Inter-TSF Trusted Channel (VPN Communications)

The EAs specified for FTP_ITC.1 in the Supporting Document for the Base-PP shall be applied for IPsec VPN communications.
The EAs specified for FTP_ITC.1 in the Supporting Document for the Base-PP shall be applied for IPsec VPN communications.
The EAs specified for FTP_ITC.1 in the Supporting Document for the Base-PP shall be applied for IPsec VPN communications. Additional testing for IPsec is covered in FCS_IPSEC_EXT.1.

FPF_MFA_EXT.1 Multifactor Authentication Filtering

The evaluator shall examine the TSS to verify that it describes how authentication packets are identified and how all other traffic is blocked until secondary authentication is successful.
The evaluator shall examine the operational guidance to verify that it provides instructions to the administrator on how to configure the secondary HOTP or TOTP factors and any additional details necessary for filtering all other traffic.

• Test 1: For each included selection the evaluator shall configure the TOE per the operational guidance. The evaluator shall attempt to connect and verify other traffic is rejected per the filtering rules. The evaluator shall then provide the selected factor and confirm it is accepted and traffic is no longer blocked.

FCS_EAP_EXT.1 EAP-TLS

The evaluator shall verify that the TSS describes the use of EAP options for each of the selected peer authentication mechanisms, that TLS with mutual authentication is used, that the random values are from an appropriate source, and that the EAP MSK is derived from the TLS master key and is used as the IKEv2 shared key.
The evaluator shall verify that the guidance documents describe any configurable features of the EAP or TLS functionality, including instructions for configuration of the authenticators and registration processes for clients.
Testing for TLS functionality is in accordance with the TLS package. For each supported EAP method claimed in FCS_EAP_EXT.1.1 and for each authentication method claimed in FCS_EAP_EXT.1.3, the evaluator shall perform the following tests:

• Test 1: The evaluator shall follow AGD guidance to configure the TSF to use the EAP method claimed. The evaluator shall follow AGD guidance to configure the TSF to use the authentication method claimed and, for EAP-TTLS, register a client with appropriate key material required for the authentication method. The evaluator shall establish a VPN session using a test client with a valid certificate and, for EAP-TTLS, configured to provide a correct value for the configured authenticator. The evaluator shall observe that the VPN session is successful.
• Test 2: (conditional for EAP-TTLS support): The evaluator shall cause the test client with a valid certificate to send an invalid authenticator for the claimed authentication method: For HOTP, replay the HOTP value sent previously, For TOTP or PSK, modify a byte of the properly constructed value and observe that the TSF aborts the session.
• Test 3: The evaluator shall establish a new, valid certificate for a test client using an identifier not corresponding to a registered user. For EAP-TTLS, the evaluator shall cause the test client using this certificate to send a correct authenticator value for the registered user. The evaluator shall initiate a VPN session from the test client to the TSF and observe that the TSF aborts the session.
• Test 4: The evaluator shall follow AGD guidance to configure the TSF to use a supported EAP method and register the user with key material required for a supported authentication method. The evaluator shall configure a test client to respond to an IKE v2 exchange with EAP-request, providing valid phase 1 handshake and valid TLS handshake, but computing the phase 2 shared key using standard (non-EAP) methods. The evaluator shall initiate a VPN session between the test client and the TSF, and observe that the TSF aborts the session.

FIA_HOTP_EXT.1 HMAC-Based One-Time Password Pre-Shared Keys

The evaluator shall confirm the TSS describes how the TOE complies with the RFC.
The evaluator shall confirm the TSS describes how the HOTP seed is generated and ensure it aligns with FCS_RBG_EXT.1.
The evaluator shall confirm the TSS describes how the HOTP seed is protected and ensure it aligns with the storage requirements of the Base-PP.
The evaluator shall confirm the TSS describes how a new HOTP seed is assigned for each client and how each client is uniquely identified.
The evaluator shall confirm the TSS describes how the HOTP seed is conditioned into an HOTP hash and verify it matches the selection in FIA_HOTP_EXT.1.4.
The evaluator shall confirm the TSS describes how the HOTP hash is truncated and verify it matches the selection in FIA_HOTP_EXT.1.5.
The evaluator shall confirm the TSS describes how the TOE handles multiple incoming invalid requests and verify it provides an anti-hammer mechanism that matches the selections made in FIA_HOTP_EXT.1.6.
The evaluator shall confirm the TSS describes how the TOE handles resynchronization and how it rejects attempts outside of the look-ahead window selected in FIA_TOTP_EXT.1.7.
The evaluator shall confirm the TSS describes how the TOE counter is incremented after each successful authentication.
The evaluator shall verify the operational guidance contains all configuration guidance for setting any administrative value that is configurable in the FIA_HOTP_EXT.1 requirements.
The evaluator shall configure the TOE to use a supported HOTP factor then:

• Test 1: Attempt to establish a connection using a factor from a different client. The test passes if the client fails to connect.
• Test 2: Attempt multiple connections outside the limits set in FIA_HOTP_EXT.1.6 and verify the remediation is triggered. The test passes if remediation is triggered as defined in the selections and assignments.
• Test 3: Attempt to use an HOTP that is outside of the value allowed for resynchronization. The test passes if the client fails to connect.
• Test 4: Attempt to connect with a valid HOTP, disconnect and attempt to authenticate again with the same HOTP value. The test passes if the client connects the first time and fails to connect the second time. If the HOTP generated is duplicated the test may be repeated.

FIA_PSK_EXT.1 Pre-Shared Key Composition

The evaluator shall examine the TSS to ensure that it identifies all protocols that allow pre-shared keys. For each protocol identified by the requirement, the evaluator shall confirm that the TSS states which pre-shared key selections are supported.
The evaluator shall examine the operational guidance to determine that it provides guidance to administrators on how to configure all selected pre-shared key options if any configuration is required.
The evaluator shall also perform the following tests for each protocol (or instantiation of a protocol, if performed by a different implementation on the TOE).

• Test 1: For each mechanism selected in FIA_PSK_EXT.1.2 the evaluator shall attempt to establish a connection and confirm that the connection requires the selected factors in the PSK to establish the connection.

FIA_PSK_EXT.2 Generated Pre-Shared Keys

If "generate" is selected, the evaluator shall confirm that this process uses the RBG specified in FCS_RBG_EXT.1 and the output matches the size selected in FIA_PSK_EXT.2.1.
The evaluator shall confirm the operational guidance contains instructions for entering generated pre-shared keys for each protocol identified in the FIA_PSK_EXT.1.1.

• Test 1: [conditional] If generate was selected the evaluator shall generate a pre-shared key and confirm the output matches the size selected in FIA_PSK_EXT.2.1.

FIA_PSK_EXT.3 Password-Based Pre-Shared Keys

The evaluator shall examine the TSS to ensure it describes the process by which the bit-based pre-shared keys are used.
Support for length: The evaluator shall check to ensure that the TSS describes the allowable ranges for PSK lengths, and that at least 64 characters or a length defined by the platform may be specified by the user.
Support for character set: The evaluator shall check to ensure that the TSS describes the allowable character set and that it contains the characters listed in the SFR.
Support for PBKDF: The evaluator shall examine the TSS to ensure that the use of PBKDF2 is described and that the key sizes match that described by the ST author.
The evaluator shall check that the TSS describes the method by which the PSK is first encoded and then fed to the hash algorithm. The settings for the algorithm (padding, blocking, etc.) shall be described, and the evaluator shall verify that these are supported by the selections in this component as well as the selections concerning the hash function itself.
For the NIST SP 800-132-based conditioning of the PSK, the required evaluation activities will be performed when doing the evaluation activities for the appropriate requirements (FCS_COP.1/KeyedHash).
The evaluator shall confirm that the minimum length is described.
The ST author shall provide a description in the TSS regarding the salt generation. The evaluator shall confirm that the salt is generated using an RBG described in FCS_RBG_EXT.1.
[conditional] If password strength meter or password denylist is selected, the evaluator shall examine the TSS to ensure any password checking functionality provided by the TSF is described and contains details on how the function operates.
The evaluator shall confirm the operational guidance contains instructions for entering bit-based pre-shared keys for each protocol identified in the requirement, or generating a bit-based pre-shared key (or both). The evaluator shall confirm that any management functions related to pre-shared keys that are performed by the TOE are specified in the operational guidance.
The guidance must specify the allowable characters for pre-shared keys, and that list must include, at minimum, the same items contained in FIA_PSK_EXT.3.2.
The evaluator shall confirm the operational guidance contains any necessary instructions for enabling and configuring password checking functionality.
Support for Password/Passphrase characteristics: In addition to the analysis above, the evaluator shall also perform the following tests on a TOE configured according to the Operational Guidance:

• Test 1: The evaluator shall compose a pre-shared key of at least 64 characters that contains a combination of the allowed characters in accordance with the FIA_PSK_EXT.1.3 and verify that a successful protocol negotiation can be performed with the key.
• Test 2: [conditional]: If the TOE supports pre-shared keys of multiple lengths, the evaluator shall repeat Test 1 using the minimum length and invalid lengths that are below the minimum length, above the maximum length, null length, empty length, or zero length. The minimum test should be successful, and the invalid lengths must be rejected by the TOE.
• Test 3: [conditional]: If the TOE initiates connections, initiate and establish a remote connection, disconnect from the connection, verify that the PSK is required when initiating the connection a second time.
• Test 4: [conditional]: If the TOE supports a password meter, the evaluator shall enter a password and verify the password checker responds per the description in the TSS.
• Test 5: [conditional]: If the TOE supports a password denylist, the evaluator shall enter a denylisted password and verify that the password is rejected or flagged as such.

FIA_PSK_EXT.4 HMAC-Based One-Time Password Pre-shared Keys Support

The evaluator shall verify the TSS describes how the HOTP is input into the client and how that value is sent to the server.
The evaluator shall verify the TSS describes how the HOTP is accepted from an incoming connection and how that value is verified, either by the TOE or by an external authentication server.
The evaluator shall verify the operational guidance contains any configuration necessary to enable HOTP.

• Test 1: The evaluator shall configure the TOE to use a supported HOTP factor, then attempt to establish a connection using that factor. The evaluator shall verify the client prompts the user for the HOTP before initiating the connection. The evaluator shall verify the server validates the HOTP or receives confirmation from an authentication server before establishing the channel.

FIA_PSK_EXT.5 Time-Based One-Time Password Pre-shared Keys Support

The evaluator shall verify the TSS describes how the TOTP is input into the client and how that value is sent to the server.
The evaluator shall verify the TSS describes how the TOTP is accepted from an incoming connection and how that value is verified, either by the TOE or by an external authentication server.
The evaluator shall verify the operational guidance contains any configuration necessary to enable TOTP.

• Test 1: The evaluator shall configure the TOE to use a supported TOTP factor, then attempt to establish a connection using that factor. The evaluator shall verify the client prompts the user for the TOTP before initiating the connection. The evaluator shall verify the server validates the TOTP or receives confirmation from an authentication server before establishing the channel.

FIA_TOTP_EXT.1 Time-Based One-Time Password Pre-Shared Keys

The evaluator shall confirm the TSS describes how the TOE complies with the RFC.
The evaluator shall confirm the TSS describes how the TOTP seed is generated and ensure it aligns with FCS_RBG_EXT.1.
The evaluator shall confirm the TSS describes how the TOTP seed is protected and ensure it aligns with the storage requirements of the Base-PP.
The evaluator shall confirm the TSS describes how a new TOTP seed is assigned for each client and how each client is uniquely identified.
The evaluator shall confirm the TSS describes how the TOTP seed is conditioned into a TOTP hash and verify it matches the selection in FIA_TOTP_EXT.1.4.
The evaluator shall confirm the TSS describes how the TOTP hash is truncated and verify it matches the selection in FIA_TOTP_EXT.1.5.
The evaluator shall confirm the TSS describes how the TOE handles multiple incoming requests and verify it provides an anti-hammer mechanism that matches the selections made in FIA_TOTP_EXT.1.6.
The evaluator shall confirm the TSS describes how the TOE sets a time-step value and verify it matches the selections in the ST.
The evaluator shall confirm the TSS describes how the TOE handles drift and resynchronization and verify it matches the selections. The evaluator shall ensure the TSS describes how time is kept and whether drift is calculated and recorded. If drift is recorded, the evaluator shall ensure that the TSS describes how this is done.
The evaluator shall verify the operational guidance contains all configuration guidance for setting any administrative value that is configurable in the FIA_TOTP_EXT.1 requirements.
The evaluator shall configure the TOE to use a supported TOTP factor then:

• Test 1: Attempt to establish a connection using a factor from a different client. The test passes if the client fails to connect.
• Test 2: Attempt multiple connections outside the limits set in FIA_TOTP_EXT.1.6 and verify the remediation is triggered. The test passes if remediation is triggered as defined in the selections and assignments.
• Test 3: Attempt to use a TOTP that is outside of the value allowed for resynchronization. The test passes if the client fails to connect.
Attempt to connect with a valid TOTP, disconnect and attempt to authenticate again with the same TOTP. The test passes if the client connects the first time and fails to connect the second time. If the TOTP generated is duplicated the test may be repeated.